<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html lang="en"><head>
<title>Draft: OInvite Core 1.0 - Draft 1</title>
<meta http-equiv="Expires" content="Wed, 03 Jun 2009 20:19:47 +0000">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<meta name="description" content="OInvite Core 1.0 - Draft 1">
<meta name="generator" content="xml2rfc v1.33 (http://xml.resource.org/)">
<style type="text/css"><!--
        body {
                font-family: verdana, charcoal, helvetica, arial, sans-serif;
                font-size: small; color: #000; background-color: #FFF;
                margin: 2em;
        }
        h1, h2, h3, h4, h5, h6 {
                font-family: helvetica, monaco, "MS Sans Serif", arial, sans-serif;
                font-weight: bold; font-style: normal;
        }
        h1 { color: #900; background-color: transparent; text-align: right; }
        h3 { color: #333; background-color: transparent; }

        td.RFCbug {
                font-size: x-small; text-decoration: none;
                width: 30px; height: 30px; padding-top: 2px;
                text-align: justify; vertical-align: middle;
                background-color: #000;
        }
        td.RFCbug span.RFC {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: bold; color: #666;
        }
        td.RFCbug span.hotText {
                font-family: charcoal, monaco, geneva, "MS Sans Serif", helvetica, verdana, sans-serif;
                font-weight: normal; text-align: center; color: #FFF;
        }

        table.TOCbug { width: 30px; height: 15px; }
        td.TOCbug {
                text-align: center; width: 30px; height: 15px;
                color: #FFF; background-color: #900;
        }
        td.TOCbug a {
                font-family: monaco, charcoal, geneva, "MS Sans Serif", helvetica, sans-serif;
                font-weight: bold; font-size: x-small; text-decoration: none;
                color: #FFF; background-color: transparent;
        }

        td.header {
                font-family: arial, helvetica, sans-serif; font-size: x-small;
                vertical-align: top; width: 33%;
                color: #FFF; background-color: #666;
        }
        td.author { font-weight: bold; font-size: x-small; margin-left: 4em; }
        td.author-text { font-size: x-small; }

        /* info code from SantaKlauss at http://www.madaboutstyle.com/tooltip2.html */
        a.info {
                /* This is the key. */
                position: relative;
                z-index: 24;
                text-decoration: none;
        }
        a.info:hover {
                z-index: 25;
                color: #FFF; background-color: #900;
        }
        a.info span { display: none; }
        a.info:hover span.info {
                /* The span will display just on :hover state. */
                display: block;
                position: absolute;
                font-size: smaller;
                top: 2em; left: -5em; width: 15em;
                padding: 2px; border: 1px solid #333;
                color: #900; background-color: #EEE;
                text-align: left;
        }

        a { font-weight: bold; }
        a:link    { color: #900; background-color: transparent; }
        a:visited { color: #633; background-color: transparent; }
        a:active  { color: #633; background-color: transparent; }

        p { margin-left: 2em; margin-right: 2em; }
        p.copyright { font-size: x-small; }
        p.toc { font-size: small; font-weight: bold; margin-left: 3em; }
        table.toc { margin: 0 0 0 3em; padding: 0; border: 0; vertical-align: text-top; }
        td.toc { font-size: small; font-weight: bold; vertical-align: text-top; }

        ol.text { margin-left: 2em; margin-right: 2em; }
        ul.text { margin-left: 2em; margin-right: 2em; }
        li      { margin-left: 3em; }

        /* RFC-2629 <spanx>s and <artwork>s. */
        em     { font-style: italic; }
        strong { font-weight: bold; }
        dfn    { font-weight: bold; font-style: normal; }
        cite   { font-weight: normal; font-style: normal; }
        tt     { color: #036; }
        tt, pre, pre dfn, pre em, pre cite, pre span {
                font-family: "Courier New", Courier, monospace; font-size: small;
        }
        pre {
                text-align: left; padding: 4px;
                color: #000; background-color: #CCC;
        }
        pre dfn  { color: #900; }
        pre em   { color: #66F; background-color: #FFC; font-weight: normal; }
        pre .key { color: #33C; font-weight: bold; }
        pre .id  { color: #900; }
        pre .str { color: #000; background-color: #CFF; }
        pre .val { color: #066; }
        pre .rep { color: #909; }
        pre .oth { color: #000; background-color: #FCF; }
        pre .err { background-color: #FCC; }

        /* RFC-2629 <texttable>s. */
        table.all, table.full, table.headers, table.none {
                font-size: small; text-align: center; border-width: 2px;
                vertical-align: top; border-collapse: collapse;
        }
        table.all, table.full { border-style: solid; border-color: black; }
        table.headers, table.none { border-style: none; }
        th {
                font-weight: bold; border-color: black;
                border-width: 2px 2px 3px 2px;
        }
        table.all th, table.full th { border-style: solid; }
        table.headers th { border-style: none none solid none; }
        table.none th { border-style: none; }
        table.all td {
                border-style: solid; border-color: #333;
                border-width: 1px 2px;
        }
        table.full td, table.headers td, table.none td { border-style: none; }

        hr { height: 1px; }
        hr.insert {
                width: 80%; border-style: none; border-width: 0;
                color: #CCC; background-color: #CCC;
        }
--></style>
</head><body>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<table summary="layout" width="66%" border="0" cellpadding="0" cellspacing="0"><tbody><tr><td><table summary="layout" width="100%" border="0" cellpadding="2" cellspacing="1">
<tbody><tr><td class="header">Draft</td><td class="header">D. Fuelling</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">Sappenin Technologies</td></tr>
<tr><td class="header">&nbsp;</td><td class="header">June 3, 2009</td></tr>
</tbody></table></td></tr></tbody></table>
<h1><br>OInvite Core 1.0 - Draft 1</h1>

<h3>Abstract</h3>

<p> The OInvite protocol helps facilitate the creation of
				unsolicited, spam-free "communications relationships" between
				various parties in unaffiliated domains or federations. 
</p>
<p> OInvite is intended to be used in systems where communication
				between two entities is controlled by the recipient of such
				communication, for example on social-networking websites. These
				systems generally do not suffer from the problem of spam, except at
				the point of "first contact", which is where a user is invited to
				become "friends" with an inviting user.
</p>
<p> Today, most "friend-requests" are restricted to closed-systems
				because the domain operator or federation controls the quantity and
				quality of such invitations. 
</p>
<p> OInivte extends this type of assurance to arbitrary systems by
				providing communication-request recipients the ability to verify
				that an invitation is not coming from a spammer.
</p><a name="toc"></a><br><hr>
<h3>Table of Contents</h3>
<p class="toc">
<a href="#anchor1">1.</a>&nbsp;
Definitions<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor2">1.1.</a>&nbsp;
Requirements Notation<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor3">1.2.</a>&nbsp;
Definitions<br>
<a href="#anchor4">2.</a>&nbsp;
Protocol Overview<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor5">2.1.</a>&nbsp;
Out of Scope<br>
<a href="#oi-verification-mechanism">3.</a>&nbsp;
OInvite Anti-Spam Verification Mechanism<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#oi-verification-mechanism-pow">3.1.</a>&nbsp;
OInvite Proof of Work (POW) Mechanism<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor6">3.1.1.</a>&nbsp;
POW Tokens<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#oi-pow-verification">3.1.2.</a>&nbsp;
POW Token Verification<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#other-verification-mechanisms">3.2.</a>&nbsp;
Other Potential Verification Mechansisms<br>
<a href="#oi-verification">4.</a>&nbsp;
OInvite Verification<br>
<a href="#oi-message-format">5.</a>&nbsp;
OInvite Message Format<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor18">5.1.</a>&nbsp;
OInvite Request Elements<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor19">5.1.1.</a>&nbsp;
OID<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor20">5.1.2.</a>&nbsp;
FirstName<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor21">5.1.3.</a>&nbsp;
LastName<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor22">5.1.4.</a>&nbsp;
PhoneNumber<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor23">5.1.5.</a>&nbsp;
InvitorId<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor24">5.1.6.</a>&nbsp;
InviteeId<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor25">5.1.7.</a>&nbsp;
VerificationType<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor26">5.1.8.</a>&nbsp;
POWToken<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#xml-schema-creationDate">5.1.9.</a>&nbsp;
CreationDate<br>
&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor28">5.2.</a>&nbsp;
OInvite Response Elements<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor29">5.2.1.</a>&nbsp;
OID<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor30">5.2.2.</a>&nbsp;
Response<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor31">5.2.3.</a>&nbsp;
responseReason<br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="#anchor32">5.2.4.</a>&nbsp;
CreationDate<br>
<a href="#anchor33">Appendix&nbsp;A.</a>&nbsp;
Non-Normative Examples<br>
<a href="#anchor34">Appendix&nbsp;A.1.</a>&nbsp;
Example: OInvite Request<br>
<a href="#anchor35">Appendix&nbsp;A.2.</a>&nbsp;
Example: OInvite Response<br>
<a href="#oi-message-schema">Appendix&nbsp;B.</a>&nbsp;
OInvite Request/Response Schema<br>
<a href="#anchor36">Appendix&nbsp;C.</a>&nbsp;
Security Considerations<br>
<a href="#rfc.references1">6.</a>&nbsp;
Normative References<br>
<a href="#rfc.authors">§</a>&nbsp;
Author's Address<br>
</p>
<br clear="all">

<a name="anchor1"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.1"></a><h3>1.&nbsp;
Definitions</h3>

<a name="anchor2"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.1.1"></a><h3>1.1.&nbsp;
Requirements Notation</h3>

<p>
					The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
					"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
					this document are to be interpreted as described in
					<a class="info" href="#RFC2119">[RFC2119]<span> (</span><span class="info">Bradner, B., “Key words for use in RFCs to Indicate Requirement Levels,” 1997.</span><span>)</span></a>
					.
				
</p>
<a name="anchor3"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.1.2"></a><h3>1.2.&nbsp;
Definitions</h3>

<p>
					</p>
<blockquote class="text"><dl>
<dt>Entity</dt>
<dd>A person, group of people, or system that can
							receive communications.
</dd>
<dt>Communications Relationship</dt>
<dd> An agreement between two parties where at least one
							participant has indicated a willingness to receive a particular
							type of communication from the other party. This term is also
							referred to using the abbreviation "CR". 
</dd>
<dt>OInvite Identifier </dt>
<dd> An collection of numbers and/or characters that,
							taken as a whole, is immutable and universally unique (For
							example, an RFC-2822 email address).
</dd>
<dt>OInvite Request</dt>
<dd> An invitation to join a Communications
							Relationship, commonly referred to as just an "OInvite".
</dd>
<dt>Invitor</dt>
<dd>The entity who initiates a Communications
							Relationship by sending an OInvite request.
</dd>
<dt>Invitee</dt>
<dd>The recipient of an OInvite Request.
</dd>
<dt>InvitorId</dt>
<dd>The OInvite Identifier of an OInvite Invitor.
</dd>
<dt>InviteeId</dt>
<dd>The OInvite Identifier of an OInvite Invitee.
</dd>
<dt>OInvite Verification Mechanism</dt>
<dd>One of either a Proof-Of-Work mechanism used to
							verify that the invitor exhausted a certain amount of resources
							in order to create the OInvite; or another mechanism acceptable
							to two or more federations that is defined by extending the
							OInvite Core protocol. 
</dd>
<dt>Participant</dt>
<dd>An invitor who has initiated an OInvite, or an
							invitee who has accepted an OInvite (invitors are automatically
							participants because the act of sending an OInvite indicates a
							willingness to participate). 
</dd>
</dl></blockquote><p>
				
</p>
<a name="anchor4"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.2"></a><h3>2.&nbsp;
Protocol Overview</h3>

<p>
				</p>
<ol class="text">
<li>
						OInvite specifies two types of messages: OInvite Invitations
						(OInvites) and OInvite Responses (OResponses). These messages are
						defined in section
						<a class="info" href="#oi-message-format">Section&nbsp;5<span> (</span><span class="info">OInvite Message Format</span><span>)</span></a>
						.
					
</li>
<li> When a particular user (the invitor) wishes to establish a
						Communications Relationship (CR) with another user (invitee) in an
						unafiliated domain or federation, the invitor's OInvite server
						will create a new OInvite, and transmit the invitation to the
						specified invitee via an appropriate binding. 
</li>
<li>
						Upon receiving an OInvite, the invitee's OInvite server verifies
						that the OInvite is indeed authentic per the specified OInvite
						type. Next, the server issues an OInvite Response to the invitor's
						server indicating various possible responses (e.g., accepted,
						pending, declined, etc). OInvite Responses are also defined in
						section
						<a class="info" href="#oi-message-format">Section&nbsp;5<span> (</span><span class="info">OInvite Message Format</span><span>)</span></a>
						.
						<br>
<br>

					
</li>
</ol><p>
			
</p>
<a name="anchor5"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.2.1"></a><h3>2.1.&nbsp;
Out of Scope</h3>

<p> The following attributes of this OInvite are out of scope and
					left to each implementation to define:
</p>
<p>
					</p>
<blockquote class="text"><dl>
<dt>OInvite Client-Server Interaction</dt>
<dd>OInvite Core only defines a communications
							protocol for use between OInvite servers. This document does not
							define an API or other protocol to allow an end-user to interact
							with an OInvite server to perform various operations on the
							user's established or pending OInvites, such as querying, editing
							or deleting OInvites. 
</dd>
<dt>General UI</dt>
<dd> UI Mechanisms to approve/reject an OInvite or
							reflect the state of an OInvite; Online/Offline status,
							user-messages, etc are not defined by OInvite core.
</dd>
<dt>Transport</dt>
<dd>OInvite messages are not restrcited to any
							particular transport, although the protocol family initially
							defines OInvite bindings for XMPP And HTTP. 
</dd>
<dt>OInvite Identifiers</dt>
<dd>OInvite identifiers (InvitorId and InviteeId)
							are not constrained by this spec, as they will be different based
							upon the OInvite use-case. For example, a social-networking
							website might use email addresses or URL's for these OInvite
							identifiers, while jabber clients/servers might use JID's. 
</dd>
<dt>Identifier Discovery</dt>
<dd>OInvite Identifier (InvitorId and InviteeId)
							Discovery is also out-of-scope for OInvite core. It is
							anticipated that the vast majority of use-cases will be able to
							utilize the forthcoming XRD (www.xrd.org) protocol for
							discovering information about a particular identifier. 
</dd>
</dl></blockquote><p>
				
</p>
<a name="oi-verification-mechanism"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3"></a><h3>3.&nbsp;
OInvite Anti-Spam Verification Mechanism</h3>

<p> One of the main purposes of OInvite is the prevention of
				invitation spam in open communications networks. OInvite
				accomplishes this purpose via an extensible mechanism called the
				OInvite Verification Mechanism. OInvite-Core defines a single
				Verification Mechanism called Proof-Of-Work (POW), which utilizes
				hash-based computational tokens to ensure that OInvite senders pay a
				reasonable resource cost to create new OInvites. 
</p>
<p> At the same time, utilizing POW for OInvite verification is a
				trivial operation from a resource consumption perspective, shifting
				the resource burden (economic, hardware, etc) to the OInvite
				creator.
</p>
<p> POW provides an efficiently verifiable mechanism to ensure that
				high-volume sending (i.e., bulk sending) of OInvites is non-trivial
				and expensive, thereby reducing the economic attractiveness of
				spamming at the invitation level.
</p>
<p>
				It is recognized that proof-of-work schemes may not be the only
				desirable mechanism employed to prevent "friend-request" spam. Thus,
				OInvite allows for a pluggable Anti-Spam Verification Mechanism that
				allows other types of OInvite verification to be utilized. See
				<a class="info" href="#other-verification-mechanisms">Section&nbsp;3.2<span> (</span><span class="info">Other Potential Verification Mechansisms</span><span>)</span></a>
				for more details.
			
</p>
<a name="oi-verification-mechanism-pow"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1"></a><h3>3.1.&nbsp;
OInvite Proof of Work (POW) Mechanism</h3>

<p> OInvite specifies a single anti-spam mechanism called POW. POW
					utilizes a CPU cost-function to generate a token which can be used
					as a proof-of-work. POW tokens require very little CPU power to
					verify. For more details of POW tokens, please reference prior work
					by Dwork and Naor[1] and Juels and Brainard[2], and Adam Back[1]
					(TODO - ADD THESE AS REAL REFERENCES)***********.
</p>
<a name="anchor6"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1"></a><h3>3.1.1.&nbsp;
POW Tokens</h3>

<p>POW Tokens are created by calculating an n-bit partial hash
						collision, which ensures that a computationally expensive
						operation must be performed in order to create a new token, and
						thus a new OInvite. 
</p>
<p>The OInvite Token format is a derivative of the HashCash
						protocol, with all OInvite tokens being compatible with the
						Hashcash (***REFERENCE***) V1 stamp format. OInvite uses HashCash
						extension fields to include more information in the token, such as
						the invitorId in order to prevent re-use of OInvite tokens by
						banned servers.
</p>
<p>
						
</p><p>An OInvite POW token consists of the following
								fields: version, claimed_value, creation_date, inviteeId, and a
								Hashcash extension field. Each field is described in more detail
								below. 
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>[version]:[claimed_value]:[creation_date]
     :[inviteeId]:[extension]:[rand]:[counter]
</pre></div>
					

<a name="anchor7"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.1"></a><h3>3.1.1.1.&nbsp;
POW Token: version</h3>

<p>The 'version' field is always '1', with new versions of
							OInvite potentially specifying new POW Token version numbers.
</p>
<a name="anchor8"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.2"></a><h3>3.1.1.2.&nbsp;
POW Token: claimed_value</h3>

<p>The 'claimed_value' field indicates the number of bits that
							a particular OInvite POW token claims to contain. Higher values
							are more expensive to "mint", with the approximate token creation
							time doubling for every single increase in a token's claimed
							value.
</p>
<a name="anchor9"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.3"></a><h3>3.1.1.3.&nbsp;
POW Token: creation_date</h3>

<p>
							The 'creation_date' field represents the date and time that an
							OInvite was created. OInvite POW creationDates take the same
							format at the OInvite creationDate defined in
							<a class="info" href="#xml-schema-creationDate">Section&nbsp;5.1.9<span> (</span><span class="info">CreationDate</span><span>)</span></a>
							.
						
</p>
<a name="anchor10"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.4"></a><h3>3.1.1.4.&nbsp;
POW Token: inviteeId</h3>

<p>The 'inviteeId' field is the globally unique identifier of
							the entity being invited into the communications relationship. 
						
</p>
<a name="anchor11"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.5"></a><h3>3.1.1.5.&nbsp;
POW Token: Extension Field</h3>

<p>The POW token extension field allows for additional fields
							that can be used in the POW token signature in order to force the
							token to depend on additional information not found in the
							default POW token fields. 
</p>
<a name="anchor12"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.5.1"></a><h3>3.1.1.5.1.&nbsp;
POW Token: Extension Field Format</h3>

<p>
								
</p><p>The POW Token extension field supports name/value
										pairs, and has the following format: 
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>[name1[=val1[,val2...]];[name2[=val1[,val2...]]...]]
</pre></div>
							

<p>Note that the value of an extension field can also contain
								the equals sign ('='). However, the first equal sign after a
								semi-colon for any name/value pair is considered to be a
								delimiter equal-sign. 
</p>
<a name="anchor13"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.5.2"></a><h3>3.1.1.5.2.&nbsp;
POW Token: Extension Field Example</h3>

<p>
								
</p><p>As an example, the following extension field value
										would be interpreted as follows: extension 'name1' has values
										'2' and '3'; extension 'name2' has no values; extension
										'name3' has three values 'var1=2', 'var2=3', '2', and 'val'. 
									
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>name1=2,3;name2;name3=var1=2,var2=3,2,val
</pre></div>
							

<a name="anchor14"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.5.3"></a><h3>3.1.1.5.3.&nbsp;
POW Token: Required Extension Fields</h3>

<p>OInvite POW tokens require an extension field named
								'invitorId'. This additional field is included for two reasons.
								First, if a particular spammer creates a myriad of POW tokens
								for a group of users, it will be useful to be able to ban the
								spammer based upon a particular sending address (the invitorId).
								Without this field included in the POW token, a banned spammer
								would be able to re-use his pre-calculated stamps with a
								different 'invitorId' without having to recompute them. 
</p>
<p> Second, including the 'invitorId' in the POW token collision
								calculation guards against a Man-in-the-Middle attack where an
								attacker might execute the following attack: 1.) intercept an
								OInvite before a particular invitee (recipient) has encountered
								it; 2.) change the details of the OInvite; and 3.) utilize the
								token (and a potential victim's resources to compute the token)
								without the invitor's knowledge.
</p>
<a name="anchor15"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.6"></a><h3>3.1.1.6.&nbsp;
POW Token: rand </h3>

<p> The 'rand' field is a string of random characters from the
							alphabet [a-zA-Z0-9+/=] that acts as a random salt to guard
							against birthday paradox collisions which can shortcut the
							effectiveness of this proof-of-work scheme. 
</p>
<a name="anchor16"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.7"></a><h3>3.1.1.7.&nbsp;
POW Token: counter</h3>

<p> In order to find a unique POW token with the desired number of
							collision bits, the algorithm needs to calculate the hash on
							potentially many different strings. This counter is incremented
							on each try in order to provide more opportunities for hash
							collisions. The 'counter' is composed of characters from the
							alphabet [a-zA-Z0-9+/=] (Note that an implementation is not
							required to count sequentially). 
</p>
<a name="anchor17"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.1.8"></a><h3>3.1.1.8.&nbsp;
Example POW Token</h3>

<p>
							
</p><p>The following is an example of an OInvite POW token
									sent from 'john@example.com' to 'beth@example.com' with a
									claimed_value of 20 bits (TODO - Recalculate this for 2009 year
									-- it is actually from 2006). 
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>1:20:20090501:beth@example.com:invitorid=john@example.org
     :n3kJezowv+9IkBF6:00000000000000098812
</pre></div>
						

<a name="oi-pow-verification"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.1.2"></a><h3>3.1.2.&nbsp;
POW Token Verification</h3>

<p> If appropriate, the contents of an OInvite's POW Token SHOULD
						be verified before an OInvite is accepted by a particular OInvite
						server. 
</p>
<p> Verifying the POW Token is very simple, and can be accomplished
						by taking the SHA-256 hash of the POW Token, and then counting the
						number of most significant 0 bits that are output by the SHA-256
						function. 
</p>
<p> For example, the POW Token
						'1:20:040806:foo::65f460d0726f420d:13a6b8' (****CREATE A NEW TOKEN
						HERE*****)yields an SHA-256 output of
						'00000f91d51a9c213f9b7420c35c62b5e818c23e', in which the 5 most
						significant hex digits (20 most significant bits) are 0. 
</p>
<p> Implementations MUST also inspect the creationDate to ensure
						that the token was not created more than 2 days in the future, and
						not more than 2 days in the past. This 4-day window provides
						adequate padding to account for time and zone differences among
						servers, and equally protects against mass minting attacks that
						target specific dates and/or times in the future.
</p>
<p> Additionally, implementation MAY also wish to verify the
						InviteeId to ensure it represents a valid user on the system. 
</p>
<a name="other-verification-mechanisms"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.3.2"></a><h3>3.2.&nbsp;
Other Potential Verification Mechansisms</h3>

<p> OInvite leaves room for other anti-spam verification mechanisms,
					such as reputation systems, other proof-of-work schemes, or other
					mechanisms that have not yet been described. These mechanisms are
					not specified by this protocol, but can be implemented by defining
					a new 'type' parameter in OInvite Request and Response messages. 
				
</p>
<a name="oi-verification"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.4"></a><h3>4.&nbsp;
OInvite Verification</h3>

<p> Before accepting a particular OInvite and otherwise prompting or
				alerting an Invitee, implementations SHOULD verify the contents of
				an OInvite per the following:
</p>
<p>
				</p>
<ol class="text">
<li>
						Inspect the powToken element and verify its contents per the
						instructions in
						<a class="info" href="#oi-pow-verification">Section&nbsp;3.1.2<span> (</span><span class="info">POW Token Verification</span><span>)</span></a>
						.
						<br>
<br>

					
</li>
<li>
						Verify the value of the 'InviteeId' element to ensure that it
						represents a valid user on the system.
						<br>
<br>

					
</li>
<li>
						Verify the valud of the 'InvitorId' element to ensure that it
						represents a sender that is not flagged by some other spam-related
						resource, such as a black-list.
						<br>
<br>

					
</li>
<li> Verify that the OInvite includes all necessary elements, such
						as an 'oid' and 'verificationType'. 
</li>
</ol><p>
			
</p>
<a name="oi-message-format"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5"></a><h3>5.&nbsp;
OInvite Message Format</h3>

<p>
				OInvite defines a message format using XML that conforms to the
				Relax-NG schema defined in
				<a class="info" href="#oi-message-schema">Appendix&nbsp;B<span> (</span><span class="info">OInvite Request/Response Schema</span><span>)</span></a>
				.
			
</p>
<a name="anchor18"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1"></a><h3>5.1.&nbsp;
OInvite Request Elements</h3>

<a name="anchor19"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.1"></a><h3>5.1.1.&nbsp;
OID</h3>

<p> This is a globally unique identifier for an OInvite. Because an
						OInvite is initiated by the invitor's server, the oid is created
						by the sender of an OInvite and is unique to that domain or
						federation.
</p>
<p>
						For some best practices on how to create a globally unique
						identifiers, consult
						<a class="info" href="#RFC4287">[RFC4287]<span> (</span><span class="info">Nottingham, M. and R. Sayre, “The Atom Syndication Format,” 2005.</span><span>)</span></a>
						and
						<a class="info" href="#RFC4151">[RFC4151]<span> (</span><span class="info">Kindberg, T. and S. Hawke, “The 'tag' URI Scheme,” 2005.</span><span>)</span></a>
						.
					
</p>
<a name="anchor20"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.2"></a><h3>5.1.2.&nbsp;
FirstName</h3>

<p> The optional first-name of an invitor, limited to fifteen (15)
						UTF-8 characters. It is recommended that implementations remove
						certain inappropriate words from this field as appropriate in
						order to present the most appropriate information to an invitee. 
					
</p>
<a name="anchor21"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.3"></a><h3>5.1.3.&nbsp;
LastName</h3>

<p> The optional last-name of an invitor, limited to fifteen (15)
						UTF-8 characters. It is recommended that implementations remove
						certain inappropriate words from this field as appropriate in
						order to present the most appropriate information to an invitee. 
					
</p>
<a name="anchor22"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.4"></a><h3>5.1.4.&nbsp;
PhoneNumber</h3>

<p> An optional telephone number for the invitor. Implementations
						should allow only numbers, dashes, periods, spaces and letters to
						indicate an extension. 
</p>
<a name="anchor23"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.5"></a><h3>5.1.5.&nbsp;
InvitorId</h3>

<p> The globally unique identifier of the Invitor (the OInvite
						sender).
</p>
<a name="anchor24"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.6"></a><h3>5.1.6.&nbsp;
InviteeId</h3>

<p> The globally unique identifier of the Invitee (the OInvite
						recipient).
</p>
<a name="anchor25"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.7"></a><h3>5.1.7.&nbsp;
VerificationType</h3>

<p> The type of verification mechanism that should be utilized to
						verify this OInvite. 
</p>
<p>
						
</p><p>OInvite-Core defines two values:
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>"NONE"
</pre></div>
					

<p> and 
</p>
<p>
						
</p><p>
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>"POW"
</pre></div>
					

<p> "None" indicates that an OInvite request has no Verification
						Type (for use in closed-systems). 
</p>
<p>
						"POW" indicates the use of the proof-of-work mechanism defined in
						section
						<a class="info" href="#oi-verification-mechanism-pow">Section&nbsp;3.1<span> (</span><span class="info">OInvite Proof of Work (POW) Mechanism</span><span>)</span></a>
						.
					
</p>
<a name="anchor26"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.8"></a><h3>5.1.8.&nbsp;
POWToken</h3>

<p>
						A string that specifies a token in the format defined in
						<a class="info" href="#oi-verification-mechanism-pow">Section&nbsp;3.1<span> (</span><span class="info">OInvite Proof of Work (POW) Mechanism</span><span>)</span></a>
						. This token is calculated using a derivative of the HashCash
						algorithm (www.hashcash.org) which relies on the properties of
						n-bit partial hash collisions to ensure a computationally
						expensive operation must be performed in order to create a valid
						OInvite.
					
</p>
<p> This field is required only if the VerificationType is 'POW',
						or as otherwise specified by an OInvite extension. 
</p>
<a name="xml-schema-creationDate"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.9"></a><h3>5.1.9.&nbsp;
CreationDate</h3>

<p>
						The date/time that this OInvite was created by the Invitor. The
						value of this field must conform to
						<a class="info" href="#RFC3339">[RFC3339]<span> (</span><span class="info">Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” 2002.</span><span>)</span></a>
						and take the following format: [YYYY-MM-DD]T[HH:MM:SS]+/-hh:mm or
						[YYYY-MM-DD]T[HH:MM:SS]'Z'.
					
</p>
<p>
						
</p><p>OInvite Date/Time Example representing 6/1/2009
								@ 03:30:22 PM EST.
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>2009-06-01T08:30:22-05:00
</pre></div>
					

<a name="anchor27"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.1.9.1"></a><h3>5.1.9.1.&nbsp;
Timestamp Differences Between RFC3339 and RFC2822</h3>

<p> The SMTP time standard differs from the ATOM specification in
							the area of offsets and offset formatting. For example, RFC2822
							(SMTP) mandates that an offset take the form "+/-0000", where no
							colon is used to separate the hours and minutes of the offset. In
							addition, the trailing 'Z' cannot be used to denote UTC. Instead,
							'+0000' is used to denote UTC, and '-0000' is used to indicate
							that an offset is not known. Atom, on the other hand, uses a
							colon between the hour and minutes in the offset, and specifies a
							UTC by using the 'Z' indicator. 
</p>
<a name="anchor28"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.2"></a><h3>5.2.&nbsp;
OInvite Response Elements</h3>

<a name="anchor29"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.2.1"></a><h3>5.2.1.&nbsp;
OID</h3>

<p> This is a globally unique identifier for an OInvite. This value
						should match the oid of a corresponding OInvite Request.
</p>
<a name="anchor30"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.2.2"></a><h3>5.2.2.&nbsp;
Response</h3>

<p> One of either 'SUCCESS', 'FAILURE', or 'INVALID'. 
</p>
<p> 'SUCCESS' is used to indicate that the invitee has accepted the
						OInvite and agrees to enter into a communications relationship.
</p>
<p> 'FAILURE' is used to indicate that the invitee has declined the
						OInvite, and does not wish to enter into a communications
						relationship. 
</p>
<p> 'INVALID' is used to indicate that the OInvite was invalid or
						otherwise unacceptable to the invitee's OInvite server. 
</p>
<a name="anchor31"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.2.3"></a><h3>5.2.3.&nbsp;
responseReason</h3>

<p> A textual string that can be used to augment the 'response',
						such as why an OInvite failed or was invalid. 
</p>
<a name="anchor32"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.5.2.4"></a><h3>5.2.4.&nbsp;
CreationDate</h3>

<p>
						The date/time that this OInvite Response was created by the
						Invitee. The value of this field must conform to
						<a class="info" href="#RFC3339">[RFC3339]<span> (</span><span class="info">Klyne, G. and C. Newman, “Date and Time on the Internet: Timestamps,” 2002.</span><span>)</span></a>
						and take the following format: [YYYY-MM-DD]T[HH:MM:SS]+/-hh:mm or
						[YYYY-MM-DD]T[HH:MM:SS]'Z'.
					
</p>
<p>
						
</p><p>OInvite Date/Time Example representing 6/1/2009
								@ 03:30:22 PM EST.
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>2009-06-01T08:30:22-05:00
</pre></div>
					

<a name="anchor33"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.A"></a><h3>Appendix A.&nbsp;
Non-Normative Examples</h3>

<a name="anchor34"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.A.1"></a><h3>Appendix A.1.&nbsp;
Example: OInvite Request</h3>

<p>
					The following is an example of an OInvite Request:
					
</p><p>Example:
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>&lt;oinvite:request version="1.0" xmlns="http://www.oinvite.net/core/1.0"&gt;
	&lt;oid&gt;tag:foo.com,2005:8.3093&lt;/id&gt;
     &lt;firstName&gt;Bob&lt;/firstName&gt;
     &lt;lastName&gt;Jones&lt;/lastName&gt;
     &lt;phoneNumber&gt;801-555-1234&lt;/phoneNumber&gt;
     &lt;invitor&gt;bob@foo.com&lt;/invitor&gt;
     &lt;invitee&gt;alice.smith@bar.com&lt;/invitee&gt;
     &lt;verificationType&gt;POW&lt;/verificationType&gt;
     &lt;powToken&gt;1:20:20090501:beth@example.com:invitorid=john@example.org
        :n3kJezowv+9IkBF6:00000000000000098812&lt;/powToken&gt;
     &lt;creationDate&gt;2009-06-01T18:30:02.25+01:00&lt;/creationDate&gt;
     &lt;extension/&gt;
&lt;/oinvite:request&gt;
</pre></div>
				

<a name="anchor35"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.A.2"></a><h3>Appendix A.2.&nbsp;
Example: OInvite Response</h3>

<p>
					
</p><p>The following is an example of a successful OInvite
							Response where an invitee has accepted an OInvite:
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>&lt;oinvite:request version="1.0" xmlns="http://www.oinvite.net/core/1.0"&gt;
     &lt;oid&gt;tag:foo.com,2005:8.3093&lt;/id&gt;
     &lt;response&gt;SUCCESS&lt;/response&gt;
     &lt;creationDate&gt;2009-06-01T18:30:02.25+01:00&lt;/creationDate&gt;
     &lt;extension/&gt;
&lt;/oinvite:request&gt;
</pre></div>
				

<a name="oi-message-schema"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.B"></a><h3>Appendix B.&nbsp;
OInvite Request/Response Schema</h3>

<p>
				
</p><p>
</p><div style="display: table; width: 0pt; margin-left: 3em; margin-right: auto;"><pre>namespace oinvite = "http://www.oinvite.net/ns/core/1.0"

## Represents two possible OInvite document types
start = oinvite:oirequest | oinvite:oiresponse

## The only common element is the version.
element oinvite:commonattributes {
    attribute version { xsd:string },
}

element oinvite:oirequest
{
     element oinvite:oid { text },
     element oinvite:invitorId { text },
     element oinvite:firstName { text }?,
     element oinvite:lastName { text }?,
     element oinvite:phoneNumber { text }?,
     element oinvite:inviteeId { text },
     element oinvite:verificationType { text },
     element oinvite:powToken { text },
     element oinvite:creationDate { text },
     oinvite:extension?
}

element oinvite:oirequest {
     element oinvite:oid { text },
     element oinvite:creationDate { text },
     element oinvite:response { text },
     oinvite:extension?
}
</pre></div>
			

<a name="anchor36"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<a name="rfc.section.C"></a><h3>Appendix C.&nbsp;
Security Considerations</h3>

<p>
				</p>
<blockquote class="text"><dl>
<dt></dt>
<dd>
</dd>
</dl></blockquote><p>
			
</p>
<a name="rfc.references1"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<h3>6.&nbsp;Normative References</h3>
<table width="99%" border="0">
<tbody><tr><td class="author-text" valign="top"><a name="RFC2119">[RFC2119]</a></td>
<td class="author-text">Bradner, B., “<a href="http://tools.ietf.org/html/rfc2119">Key words for use in RFCs to Indicate Requirement Levels</a>,” RFC&nbsp;2119, 1997.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC2616">[RFC2616]</a></td>
<td class="author-text">Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “<a href="http://tools.ietf.org/html/rfc2616">Hypertext Transfer Protocol -- HTTP/1.1</a>,” RFC&nbsp;2616.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3339">[RFC3339]</a></td>
<td class="author-text">Klyne, G. and C. Newman, “<a href="http://tools.ietf.org/html/rfc3339">Date and Time on the Internet: Timestamps</a>,” RFC&nbsp;3339, 2002.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC3920">[RFC3920]</a></td>
<td class="author-text">Saint-Andre, P., “<a href="http://tools.ietf.org/html/rfc3920">Extensible Messaging and Presence Protocol (XMPP):
						Core</a>,” RFC&nbsp;3920, 2004.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4151">[RFC4151]</a></td>
<td class="author-text">Kindberg, T. and S. Hawke, “<a href="http://tools.ietf.org/html/rfc4151">The 'tag' URI Scheme</a>,” RFC&nbsp;4151, 2005.</td></tr>
<tr><td class="author-text" valign="top"><a name="RFC4287">[RFC4287]</a></td>
<td class="author-text">Nottingham, M. and R. Sayre, “<a href="http://tools.ietf.org/html/rfc4287">The Atom Syndication Format</a>,” RFC&nbsp;4287, 2005.</td></tr>
</tbody></table>

<a name="rfc.authors"></a><br><hr>
<table summary="layout" class="TOCbug" align="right" cellpadding="0" cellspacing="2"><tbody><tr><td class="TOCbug"><a href="#toc">&nbsp;TOC&nbsp;</a></td></tr></tbody></table>
<h3>Author's Address</h3>
<table width="99%" border="0" cellpadding="0" cellspacing="0">
<tbody><tr><td class="author-text">&nbsp;</td>
<td class="author-text">David Fuelling</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Sappenin Technologies, LLC</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">Salt Lake City, UT  84117</td></tr>
<tr><td class="author-text">&nbsp;</td>
<td class="author-text">USA</td></tr>
<tr><td class="author" align="right">Email:&nbsp;</td>
<td class="author-text"><a href="mailto:sappenin@gmail.com">sappenin@gmail.com</a></td></tr>
<tr><td class="author" align="right">URI:&nbsp;</td>
<td class="author-text"><a href="http://www.oinvite.net/">http://www.oinvite.net</a></td></tr>
</tbody></table>
</body></html>